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AfiS, TRACT 


A  Programmer's  Interface  (PI)  Is  a  system  whlc,  transforms  an  Interpretive  1  anguage 
Into  a  programming  system  by  providing  a  1 anguage- I ndependent  set  of  "environment"  tools 
to  be  used  In  conjunction  with  the  execution  capabilities  of  the  Interpretive  language. 
This  "environment"  consists  of  tools  for  creating,  editing,  debugging,  filing  and 
retrieving  programs,  for  automatic  spelling  correction,  for  modifying  and  reissuing 
previous  commands,  and  for  undoing  them  to  recover  earlier  states.  A  PI  thus  greatly 
expands  the  facilities  available  for  program  development  without  affecting  the 
programml  ng  language  or  Its  capabilities.  The  Importance  of  such  a  transformation 
cannot  be  overstated  In  terms  of  programmer  productivity. 

Any  language  with  the  following  three  properties  can  be  interfaced  to  a  PI  at  a 
fraction  of  the  cost  (several  man-days  versus  several  man-years)  of  creating  a  separate 
suitable  programming  system  I fs  I)  there  is  a  way  to  form  a  coroutine  linkage  between 
the  language  processor  and  the  PI  by  Interconnecting  their  I/O  ports;  2)  the  language 
has  an  on-line  evaluator  and  can  field  breaks  or  errors  within  a  computation;  and  3) 
either  in  such  breaks  or  at  the  top  level,  the  evaluator  can  evaluate  arbitrary  forms  In 
that  language. 

A  particular  system  (PI-1)  has  been  constructed  as  an  Instance  of  the  PI  concept, 
using  INTERLISP,  and  It  provides  INTERLISP's  tools  to  interfaced  languages.  This  PI  has 
been  successfully  Interfaced  to  ECL  using  the  ARPA  Network  as  the  communications 
mechanism.  The  significance  of  this  work  lies  In  the  observation  that  very  little  of 
the  PI  or  the  capabilities  available  In  the  INTERLISP  programming  environment  are 
I anguage-dependent,  and  In  the  experience  gained  in  determining  how  a  PI  should  be 
constructed  and  how  languages  should  be  interfaced  to  I c,  rather  than  In  the  Interfacing 
between  the  PI  and  any  particular  language. 

This  work  Is  of  special  relevance  to  large  DOD-MIlltary  software  production 
efforts.  The  research  Is  directed  toward  h'gher  productivity  and  higher  quality 
software.  This  work  Is  sponsored  under  ARPA  Contract  No.  0AHC15  72  C  030 8,  ARPA  Order 
No.  2223/1,  Program  Code  No.  3030  and  3PI0. 
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INTRODUCTION 


This  paper  addresses  the  general  problem  of  creating  a  suitable  on- II ne  environment 
for  programming.  The  amount  of  software,  and  the  effort  required  to  produce  It,  to 

support  such  an  on-line  environment  Is  very  large  relative  to  that  needed  to  produce  a 

programming  language,  and  Is  largely  responsible  for  the  scarcity  of  such  programming 
environments.  The  size  of  this  effort  was  largely  responsible  for  the  scrapping  of  a 

major  language  (QA4£lJ)  as  a  separate  entity  and  Its  Inclusion  I nstead  as  a  set  of 

extensions  In  a  LISP£2]  environment.  The  few  systems  whl "h  do  exist  (e.g..  LISP, 
APL£3],  BASIC£4J,  and  PL/I£5])  have  greatly  benefited  their  users  and  have  strongly 
contributed  to  the  widespread  acceptance  of  the  associated  language. 

At  a  pare  minimum,  a  suitable  programming  environment  consists  of  an  on-line 
Interpreter  (or  Incremental  compiler),  an  integrated  Interactive  source-level  debugging 
and  editing  system,  and  a  supporting  file  structure.  More  extensive  environments  would 
include  such  facilities  as  automatic  spelling  correction,  structural  editors,  tracing 
packages,  test  case  generators,  documentation  facilities,  etc. 

Looking  at  several  programming  environment  systems,  one  recognizes  much  uniformity. 
Most  of  the  software  supporting  these  systems  Is  similar  In  both  Its  organl zat I ona I 
structure  and  functions.  The  systems  differ  In  detail  more  from  style  differences 
between  the  system  designers  than  from  differences  required  by  the  programming 
I anguages . 

The  Programmer's  Interface  (PI)  concept  attempts  to  exploit  this  uniformity  by 
creating  a  single  programming  environment  capable  of  easily  interfacing  users  with  a 
wide  variety  of  on-line  programming  languages.  Users  would  then  have  the  full 
facilities  of  this  environment  at  their  disposal.  The  PI  Is  thus  responsible  for 
transforming  these  programming  LANGUAGES  Into  SYSTEMS.  The  cost  of  providing  such  an 
environment  for  a  language  would  drop  from  the  several  man-years  now  required  to  the  few 
man-day'  (estimated)  to  interface  to  a  PI.  Additionally,  the  existence  of  a  common 
programming  environment  for  many  different  languages  would  Justify  the  inclusion  of 
further  capabl 1 1 tl es. 
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This  common  programming  environment  provided  by  a  PI  should  include  facilities  for* 
creating,  modifying,  storing,  and  retrieving  programs?  on-line  debugging,  including 
trace  and  break  facilities  as  well  as  the  facilities  of  the  language  for  evaluation  of 
expressions  at  breaks;  modlfylno  the  interface  between  routines  (via  an  ADVISEI6] 
capability);  automatic  spelling  correction?  remembering,  modifying,  and  reissuing 
previous  inputs;  and  undol no  the  effects  of  any  of  these  PI  facilities. 

Such  a  PI  has  been  constructed  and  interfaced  to  the  programming  language  E  CL  C  7  3  • 
The  remainder  of  this  paper  explains  the  PI  concept  in  terms  of  this  implemented 
program.  The  deficiencies  of  this  particular  implementation  are  discussed  in  the 
cone  1  us  1  on. 

SYSTEM  ARCHITECTURE 

The  facilities  provided  by  the  implemented  Programmer's  Interface  (PI-1)  are  based 
on  the  INTERLISP  system  (formerly  8BN-LISP) 12].  In  fact,  they  are  the  facilities  of 
this  system,  as  modified  for  language  Independence.  The  Programmer's  Interface  Itself 
Is  Implemented  in  INTERLISP  and  coexists  with  the  facilities  It  Invokes  to  provide  the 
programming  environment.  INTERLISP  was  chosen  as  the  basis  both  because  It  already  had 
an  extensive  set  of  programming  tools  In  an  accessible  form,  and  because  their  structure 
and  operation  could  easily  be  altered  to  operate  as  required  for  a  PI. 

The  system  structure  Is  shown  In  Figure  1.  The  ARPA  Network[8]  Is  used  as  the 
communications  mechanism  between  P I —  1  and  the  user's  language  processor.  This  choice 
has  three  advantages.  First,  It  allows  che  Interfacing  of  PI-I  to  any  language 
processor  aval  lable  on  the  ARPANET  Independent  of  what  machine  It  runs  on.  Second,  this 
Interfacing  can  be  done  by  Pl-i  without  the  knowledge  of  the  language  processor.  Thus 
no  modifications  to  the  language  processor  are  required.  Finally,  the  use  of  the 
Network  greatly  simplifies  implementing  the  Interconnection  by  allowing  external 
character  strings  to  be  used  for  communication,  rather  than  Internal  data  structures 
with  the  attendant  incompatibility  problems. 
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System  architecture 


Three  properties  are  required  of  a  language  processor  for  Its  use  with  a  PI* 


1)  There  Is  a  way  to  form  a  coroutine[9]  linkage  between  the  language  processor  and  tne 

PI  by  Interconnecting  their  I/O  ports.  This  type  of  linkage  Is  discussed  in  detail 

In  [10].  With  PI-1,  the  ARPA  Network  provides  this  linkage.  Thus,  for  PI-1,  any 

language  processor  available  on  the  ARPANET  satisfies  the  first  requirement. 

2)  It  has  an  on-line  evaluator  (either  an  interpreter  or  fast  compiler)  and  can  field 

breaks  or  errors  within  a  computation. 

3)  It  can  evaluate  arbitrary  forms  in  that  language  either  in  breaks  or  at  the  top 

level. 

PI-1  begins  processing  user  Input  by  storing  It  in  a  history  list  used  by  the 
Programmer's  Assistant[6]  ,  an  INTERLISP  subsystem,  to  retrieve,  edit,  group,  reissue,  or 

undo  previous  commands.  PI-1  then  examines  the  Input  to  determine  whether  It  should  be 

processed  by  an  INTERLISP  facility  or  by  the  user's  language  processor.  Basically, 

environment-type  activities,  s^ich  as  loading  files,  editing  programs,  advising  a 

function,  etc.,  are  performed  within  PI-1,  while  expressions  In  the  user's  language  to 
be  evaluated  are  passed  to  the  language  processor. 

If  the  user's  Input  is  Intended  for  his  language  processor.  It  Is  passed  across  the 
ARPA  Network  to  that  language  processor.  Any  output  generated  by  the  processor  is 
received  across  the  Network  agal n  by  PI-1.  It  suppresses  the  echo  of  the  Input  and 
passes  the  output  to  the  user,  extracting  from  It  the  "value1'  and  putting  It  Into  the 
history  list  for  use  by  the  Programmer's  Assistant. 

If  the  user's  Input  Is  an  envl r onment-type  command  and  should  be  performed  within 
PI-1,  the  appropriate  facility  is  Invoked.  In  simple  cases  the  operation  completes, 
returns  a  vblue  that  is  put  In  the  history,  and  another  Input  Is  processed.  In  more 
complex  situations,  some  Interaction  Is  required  during  the  operation  with  the  user's 
'anguage  processor.  This  Is  accomplished  by  dynamically  generating  a  series  of  Inputs 
for  the  language  processor  that  will  have  the  desired  effect  or  return  the  desired 
information.  These  are  passed  through  the  communications  mechanisms  to  the  processor; 
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Its  output  Is  captured;  and  either  the  success  of  the  modifications  Is  verified  or  the 
desired  Information  is  extracted.  Any  number  of  such  cycles  may  be  required  before  the 
PI-1  facility  completes  Its  processing  of  tl*e  user's  command.  As  an  example,  consider 
the  loading  of  a  file.  As  the  function  definitions  are  read  In,  they  are  stored  as  a 
property  of  the  corresponding  atoms  to  be  used  by  the  PI-1's  editor  for  any 
modifications  required  later.  The  function  definitions  also  are  passed  to  the  language 
processor  o  that  It  can  use  these  for  evaluation.  Thus,  one  cycle  Is  required  for  each 
function  defined  In  the  file. 

PI-1  maintains  a  copy  of  all  functions  defined  by  the  user  and  this  Is  used  by 
PI-1  s  editor  when  the  user  alters  the  definition.  Whenever  this  definition  changes  (by 
redefinition  or  through  exiting  the  editor),  the  resulting  definition  is  passed  to  the 
language  processor  as  a  new  definition  of  the  function. 

INTERFACING  A  LANGUAGE  TO  A  PROGRAMMER'S  INTERFACE 

Most  of  PI-1  Is  language-independent,  but  certain  portions  must  be  modified  to 
accept  a  new  language.  These  fall  Into  the  categories  of  syntax  modification, 
synchronization,  program  writing,  and  debugging. 

The  INTERLISP  editor  used  by  PI-1  Is  structural  rather  than  string-oriented.  To  be 
effective,  the  text  It  Is  manipulating  must  have  a  structural  basis.  The  syntax 
modification  routines  are  responsible  for  Introducing  the  structure  into  the  user's 
language  (only  for  use  vl thl n  PI-I).  This  structure  Is  of  two  forms.  First  Is  the 
grouping  of  characters  Into  lexical  units.  The  user's  language  may  have  very  different 
lexical  grouping  rules  than  LISP  and  the  syntax  modification  package  is  responsible  for 
the  lexical  analysis.  Second,  the  lexical  units  thus  produced  are  grouped  into  larger 
units  by  the  use  of  parentheses.  These  units  can  be  nested  within  one  another  to  form 
the  familiar  LISP  S-expressIon  structure.  The  designer  of  the  syntax  modifier  must 
decide  wher-s  to  introduce  this  structural  grouping.  In  ALGOL-like  languages,  a  natural 
place  would  be  to  group  the  lexical  units  of  a  statement  together  and  groups  of 
statements  within  blocks  together.  The  structural  groupings  selected  are  introduced 


Into  all  program  text  Input  by  the  user,  and  used  by  him  to  direct  the  editor  in  Its 


modifications  of  this  text.  Wherv  this  text  Is  passed  to  the  language  processor,  those 
structural  groupings  artificially  introduced  for  editing  purposes  are  removed  before 
transmi ssi on. 

PI-1  and  the  languace  processor  must  be  synchronized  and  kept  In  step  with  each 
other.  Logically  this  is  very  simple  and  is  accomplished  by  having  Pl-i  wait  until  the 
language  processor  has  completed  evaluating  the  previous  Input  before  giving  It  another. 
This  situation  is  signaled  by  the  language  processor's  attempt  to  read  the  next  input. 
Unfortunately  (cue  to  a  deficiency  in  the  network  protocol),  this  Information  Is  not 
available.  Therefore  the  language  processor's  state  of  readiness  must  be  determined  by 
examination  of  its  output  stream.  Fortunately,  most  on-line  language  processors 
explicitly  indicate  their  readiness  for  more  input  by  providing  tne  user  with  a  prompt 
character.  The  language  processor's  output  must  be  scanned  for  this  prompt  and  this  is 
used  as  a  synchronization  mechanism  between  PI-1  and  the  language  processor. 

Several  facilities  within  PI-1,  such  as  break,  trace,  and  advise,  cause  additional 
statements  to  be  written  into  the  user's  program  for  evaluation  at  runtime.  The 
interfacer  of  a  new  language  must  specify  the  form  of  these  additions. 

PI-1  contains  many  advanced  debugging  capabilities  not  found  in  most  language 
processors.  These  aids  are  all  based  on  information  gathered  during  execution  or  at  a 
break  point  within  the  program.  To  use  these  facilities,  the  designer  of  the  language 
interface  must  supply  routines  that  provide  the  basic  Information  on  which  these 
debugging  aids  are  buiit. 

PI-1  took  approximately  three  weeks  to  implement  and  debug,  including  the  language 
interface  to  ECL.  Although  no  other  ianguage  interfaces  have  yet  been  built,  it  is 
estimated  that  an  inter. ace  to  another  suitable  ianguage  could  be  designed.  Implemented, 
and  debugged  in  less  than  a  week. 

PI-l/ECL  EXAMPLE 

The  following  actual  example  indicates  the  use  of  Pl-i  with  the  programming 
language  ECL.  The  prompt  character  (as  defined  by  ECL)  is  either  ->,  *,  or  a  number 
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fo I  lowed  by  i> 


Commentary  Is  enclosed  In  square  brackets 


->  3+4 

7 

->  TESTI  <-£.XPR(  A:  INT 


(TESTI) 

->  TESTI ( 3,4 ) 

7 

->  EDITF(TSTI) 


=  TESTI 

EDIT 

*PP 


(EXPR  (A  •'  JNT  ,  B 

(BEGIN  (A  +  B) 
END)) 

•F  BEGIN  P 


[Input  of  expression  to  be  evaluated.) 
[Answer  returned.] 

,B.'INT,INT)BEGIN  A+B;  END; 

[Define  a  function, TEST  1 ,  which  takes 
two  Integer  arguments  A  and  B  and  returns 
their  sum.  Syntax  Is  precisely  as 
def I ned  for  ECL. ] 

[ TEST  I  def I ned. ] 

[Invoke.  TEST)  with  arguments  3  and  A.] 
[Answer  returned.] 

[Ed.t  TEST).  Notice  misspelling  corrected  by 
system. ] 

[Prettyprlnt  It.  Notice  how  structure 
has  been  added  to  its  internal  repre- 
sentatl on.] 

INT  ;  INT) 


(BEGIN  (A  +  B)  END) 

*(2  (A  GT  B  =>  A-L i  A+B)) 


[Find  the  I  tern  'BEGIN'  and  print  what 
Is  found.] 


►PP 


[Replace  the  second  element,  the  list  A+B, 
by  the  remainder  of  the  input.  This  Is  a 
conditional  form  in  ECL  which  evaluates 
A-B  If  A  Is  greater  than  B  and  A+B 
otherwl se. ] 

[Prettyprlnt  result.  Again  notice  how 
structure  has  been  added.] 


(BEGIN  (A  GT  B  =>  (A 
(A  +  B) 

END) 

*(-4  (A=B  ->  B  <-  2*A)) 


*PP 

(BEGIN  (A  GT  8  =>  (A  - 
(A  +  B) 

(A  =  B  ->  (B  <- 
END) 

•UNDO 


(-4  — )  UNDONE. 

*PP 

(BEGIN  (A  GT  B  =>  (A  - 
(A  +  B) 

ENO) 

•USE  -3  FOR  -4 
•PP 

(BEGIN  (A  GT  B  ->  (A  - 
(A  =  B  ->  (B  <- 
(A  +  B) 

(ENO) 


B)) 


[Insert  rest  of  Input  before  fourth 
element  of  current  structure  (the 
END  Item).  Addition  says  to  set 
B  to  2*A  If  A=B. ] 

[Prettyprlnt  It.] 

B) 

2  •  A)) 

[User  notices  his  error  (addition  made  at 
wrong  spot)  and  asks  system  to  undo  last 
command. ] 

[Check  to  see  that  It's  really  gone.] 

B)) 


[Substitute  -3  for  -4  in  the  In¬ 
sertion  command  and  reissue  It.] 

[Make  sure  addition  put  In  correct  spot.] 
B)) 

2  •  A)) 


ed 1  tor . ] 


*0K 

TEST  1 

->  TEST1 ( 3, A ) 

7 

->  TESTKA.3) 

I 

->  IESTI  (A, A) 

12 

->ADVISE( TEST  I  BSFOF 


fEST ) 

->  TEST  1(3,4) 

2 

->  USE  6  3  10  FOR  A 


15 

3 

16 

->ADVIS£(  TE.CT  1  AFTER 


TEST  1 

->  REDO  USE 


TYPE  FAULT 

-  BROKEN 
NIL 

TYPE  FAULT 

-  BROKEN 
NIL 

TYPE  FAULT 

-  BROKEN 
NIL 

3:>RETBRK(0) 

NIL 

->  TEST1 ( 3, A) 

TYPE  FAULT 

-  BROKEN 
NIL 

1 :>  IN ? 

IN  ENTRY  OR  EXIT  OF- 
IN  TEST1 ... 

VALUE \\  <-  VALUE  -  1 


1 *>EOI TF( TEST  1 ) 

EOIT 

*F  VALUE  0  P 

(VALUEW  <-  VALUE  -1 
*R  VALUE  VALUEW 


I£xi  t 

[Test  function.  A  is  less  than 
8,  just  add  them.] 

[A  greater  than  B,  subtract 
B  from  A.] 

[A=B,  double  B  and  add  in  A.] 

( A<-  2*A) ) 

[Modify  TEST1  so  that  before  it 
is  enterea,  but  after  its  parameters 
have  been  bound,  the  value  of  A 
i  s  doubled.] 

[Invoke  modified  function.] 

[Double  3  to  cet  6  and  subtract  A.] 

[Successively  substitute  6,3,  and  10 
for  A  in  the  last  statement.] 

[TEST  1(3,6)] 

[ TE^  T 1(3,3)] 

[ TEST  1 ( 3,  10)] 

(VALUEW  <-  VALUE-1  )) 

[Modify  TEST!  so  that  after  it  is 
finished,  but  before  it  returns, 
the  value  to  be  returned  is  dec¬ 
remented  by  1.] 

[Rei  ssue  the  previous  USE  command 
(which  generated  the  3  invocations  of 
TEST1  )] 


[3  type  fault  error  occur.] 

[Go  back  to  top  level.] 

[Try  simple  case.] 

[Error  still  occurs.] 

[Where  did  error  occur?] 


[Error  occurred  in  entry  or  exit  of  minus 
routine  which  was  Invoked  from  TEST!  in 
the  statement  VALUE\\<-VALUE-1 .  User 
spots  error  (use  of  the  undeclared 
variable  VALUE  instead  of  VALUEW).] 

[Edit  TEST i .3 

[FI  nd  the  use  of  VALUE.  Go  up  one 
structured  level  and  print  group.] 

[Replace  VALUE  by  VALUEW.] 


*0K 

TEST! 

1 :>T£Sri(3,4) 
(U 

1  :>~ 


NIL 

->  REDO  USE 
(17) 

(2) 

(15) 


{Exit  editor.] 

[Try  test  case  again.] 

[Double  3.  subtract  4,  then  decrement 
by  1.] 

[Go  up  one  level  of  error.  In  this 
case  to  top  level.] 

[Reinvoke  previous  USE  command.] 

[ TEST1 ( 3,6) ] 

[TESTS ( 3,3) ] 

[TEST! (3,10)] 


CONCLUSION 


An  extensive  programming  environment  has  been  created  for  the  ECL  language  through 
a  program  (PI-1)  which  allows  the  use  of  the  already  existing  INTERL ISP  facilities. 
This  greatly  expands  the  user's  facilities  for  creating,  editing,  and  debugging  his 
programs.  His  programming  language  has  been  transformed  into  a  programming  system.  The 
availability  of  a  comprehensive  set  of  "environment*  tools  working  in  conjunction  with 
the  programmer's  language  Is  extremely  Important  to  his  productivity. 

The  significance  of  this  work,  however,  lies  not  in  the  particular  Interface 
provided  between  INTERLISP  and  ECL,  nor  In  the  extensive  capabilities  provided  the  user, 
but  rather.  In  1)  the  observation  that  very  little  of  the  Interface  Itself,  or  of  the 
capabilities  provided,  are  language-dependent!  2)  the  recognition  that  the  programming 
environment  can  be  effectively  spilt  Into  an  "environment"  part  and  an  execution  and 
evaluation  parts  and  3)  the  experience  gained  from  building  such  a  system  and 
Interfacing  a  language  to  It. 

PI-1,  however,  suffers  from  a  number  of  deficiencies,  the  most  important  of  which 
Is  the  use  of  already  existing  tools  in  more  genera)  environments  than  they  were 
designed  for.  This  was  most  notable  in  the  use  of  LISP's  editor  for  nonstructured  text 
(and  the  need  therefore  to  Introduce  structure  by  parentheses)  and  the  need  to  replace 
LISP's  Input  routines  to  provide  the  proper  lexical  analysis  for  the  Interfaced 
language.  Both  of  these  problems  could  be  avoided  In  a  PI  by  having  It  use  the  syntax 
description  of  the  language  to  guide  the  Input,  and  editing  and  display  of  programs. 

One  of  the  strengtrs  of  the  PI  concept  Is  the  spilt  between  the  "environment*  part 
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and  the  evaluation  part.  This  split,  however.  Introduces  the  problem  of  communication 
and  synchronization;  each  part  must  keep  the  other  Informed  about  changes  It  makes  that 
affect  the  other.  In  PI-1,  this  communication  and  synchronization  was  pardal  and 
clumsy.  The  flow  of  Information  from  the  environment  to  the  evaluation  part  was 
adequate,  but  the  reverse  flow  was  not.  The  need  to  communicate  to  another  program 
suitable  explanations  of  what  the  state  of  the  evaluation  was,  what  the  cause  of  the 
error  was,  or  even  that  an  error  occurred  was  simply  not  en  isloned  or  planned  for. 

PI-1  has  thus  demonstrated  that  a  moderately  Integrated  PI  can  be  built  that  has 
facilities  far  beyond  what  Is  typically  available  at  a  fraction  of  the  cost.  However, 
development  of  highly  Integrated  PI  wl  1 1  have  to  await  a  better  understanding  of  the 
functional  requirements  of  a  language  processor  In  such  an  environment. 

Although  the  Programmer's  Interface  has  only  been  Interfaced  to  one  language  (ECL), 
and  although  It  only  contains  a  small  fraction  of  the  capabilities  ultimately  desired. 
It  Is  having  a  major  efiect  by  acting  as  a  prototype  for  a  major  software  project 
[11,12]  being  undertaken  to  develop  this  understanding  and  provide  a  single,  common, 
comprehensive  programming  environment  Interfaced  to  a  wide  variety  of  languages  running 
on  many  different  machines  communicating  through  a  network.  New  languages  or  machines 
cou’d  be  Interfaced  to  the  system  at  a  fraction  of  the  cost  of  providing  a  separate 
programming  environment.  Widespread  usaoe  would  Justify  the  expenditure  of  more 
resources  to  augment  and  Improve  the  capabilities  provided.  Such  a  PI  could  free  users 
from  having  to  develop  their  programs  only  with  software  available  on  their  own  machines 
and  could  provide  a  much  more  comprehensive  and  coordinated  software  development  package 
than  Is  currently  aval  ladle. 
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